|
|
Plausible Deniability
[This section under development]
The subject of "plausible
deniability" and OTFE systems is a lot more involved than "do my volume
files have any kind of identifying signature?"
"Plausible deniability" in OTFE systems is largely based on the theory
that you can claim that your volume files are not encrypted data; you don't know what
they are - you can't be expected to know every operation that your OS
carries out! Perhaps it's some corrupt data that the system recovered
at some stage?
This claim is only possible with OTFE systems which do not embed any
kind of "signature" into their encrypted data (typically an unencrypted critical data area).
FreeOTFE volume files have no such signature.
However, this simplistic approach to plausible deniability has
drawbacks:
- Encrypted data has relatively high entropy - something "corrupt
files, recovered automatically by the OS" are unlikely to have. (Recovered data
is likely to have some form of recognisable structure, or signature, somewhere within it)
- Having several GB of high-entropy data stored on your HDD,
together with an OTFE package, is likely to be viewed as "suspicious"
at the very least...
(Note: IANAL)
Legally, the presence of large
volume files (even without any form of signature) may very well be
viewed as grounds for reasonable
suspicion to be raised;
in which case further action may be taken by an attacker (e.g.
arrest, interrogation, beating, torture, and other rubber hose
cryptanalysis techniques).
Legally (in the US at least, and in theory) what it really boils down
to is: does the fact that a prosecution cannot prove that the data
held is encrypted data, together with a user's denial, produce reasonable doubt as to whether the
data is not an OTFE volume or not? Raising reasonable doubt as to what
your volumes files really are is
the aim of "plausible deniability"; leaving it up to the prosecution to
prove, beyond reasonable doubt,
they store encrypted data.
In the UK (AIUI), things are slightly different with the "Regulation of Investigatory Powers Act (RIPA)" (see http://www.legislation.hmso.gov.uk/acts/acts2000/20000023.htm),
although this is not yet in full force at time of writing (10th October
2004). Depending largely on how the courts may
interpret it, a user (as defendant) may eventually find yourself in the
position of effectively having
to prove that the data found
is not an OTFE volume (or any
other form of encrypted data).
More advanced OTFE systems go one step further: support for hidden
volumes (as FreeOTFE does).
Here, you have a "normal" OTFE volume filled with data that you have no
objection to disclosing to an attacker. Mounting the volume with a
different password causes the OTFE system to read a different part of
the "host" volume file; giving access to a separate "hidden" volume.
Here the concept of "plausible deniability" is much stronger;
theoretically an attacker is not able to determine (let alone prove)
whether or not such a hidden volume is present.
However, the implementation of such "hidden volumes" is not as trivial
as it may seem at first.
In order for this approach to be successful, the host volume file must
be
initialized by writing random data to it. This is required since the
host volume file may well have been created by simply writing 0x00's to
your HDD in order to generate a large enough file. Any hidden volume
stored within such a host volume file may well cause an attacker
suspicion as to whether a hidden volume exists. (The hidden volume will
appear as a large amount of high-entropy data, stuck in the middle of
the volume file; interrupting the neat pattern of 0x00's!)
The "random" used for this process cannot simply be pseudorandom data;
given the size of a typical volume file (even ones as small as a
MB), pseudorandom data can potentially be identified as such, and
become predictable. In this case, your hidden volume will not appear as
high-entropy data stuck in the middle of a series of 0x00 bytes, but as
high-entropy data interrupting the pattern formed by the pseudorandom
data!
Because truly random data can be difficult to rapidly generate in large
quantities using a computer. Pseudorandom data can
still be used though: by encrypting it before it is
written to the host volume file. In principle, although not as good as
a
cryptographically secure RNG, this should give the data written to the
volume file a suitable degree of entropy.
The easiest way of accomplishing this is, which will work with any
OTFE system, is to mount the host volume as per normal and overwrite
all of its free space with a single pass of pseudorandom data. The
data written to the mounted volume will be encrypted as it is written
to the host volume file.
But, this still isn't enough.
If you were to be forced to hand over the key to the outer, "host",
volume; an attacker could then apply the same analysis - but this time
to the mounted (plaintext) version of your host volume. Again, any
hidden volume may well stick out in the pattern of pseudorandom data.
The solution suggested is to encrypt your pseudorandom data before
it is used to overwrite the mounted volume's free space; any attacker
attempting to identify a hidden volume, even with the key to the outer
"host" volume, would not be able to differentiate between your
encrypted PRNG data, and encrypted hidden volume.
This all assumes the cypher used is strong enough, of course...
For obvious reasons, all such overwriting must be carried out before the hidden volume is created
(doing so afterwards would probably corrupt your hidden volume!)
|
|
